<HTML>
<HEAD>
  <!-- Created with AOLpress/2.0 -->
  <!-- AP: Created on: 6-Dec-2000 -->
  <!-- AP: Last modified: 27-Mar-2009 -->
  <TITLE>FontForge -- An outline font editor for PostScript&reg;, TrueType
  and OpenType fonts</TITLE>
  <LINK REL="icon" href="fftype16.png">
  <LINK REL="stylesheet" TYPE="text/css" HREF="FontForge.css">
</HEAD>
<BODY id="menued">
<P ALIGN=CENTER>
<IMG SRC="fontforge-banner-420.jpeg" WIDTH=420 HEIGHT=80>
<DIV class="menucontainer">
  <UL class="menubar">
    <LI class="menu">
      <A href="http://sourceforge.net/projects/fontforge/files/">Download</A>
      <UL>
	<LI>
	  <A href="http://sourceforge.net/projects/fontforge/files/fontforge-docs/"
	      >Documentation</A>
	<LI>
	  <A href="http://sourceforge.net/projects/fontforge/files/fontforge-source/"
	      >Source</A>
      </UL>
    <LI>
      <A HREF="overview.html#TOC">Introduction</A>
    <LI>
      <A href="editexample.html">Tutorial</A>
    <LI class="menu">
      <A href="fontview.html">Windows</A>
      <UL>
	<LI>
	  <A href="fontview.html" >Font</A>
	<LI>
	  <A href="charview.html" >Outline Glyph</A>
	<LI>
	  <SMALL><A href="charview.html#Debugging" >&nbsp; &nbsp;Debugging
	  TrueType</A></SMALL>
	<LI>
	  <SMALL><A href="multilayer.html" >&nbsp; &nbsp;Type3 Glyphs</A></SMALL>
	<LI>
	  <A href="bitmapview.html" >Bitmap Glyph</A>
	<LI>
	  <A href="metricsview.html" >Metrics</A>
      </UL>
    <LI class="menu">
      <A href="fontinfo.html">Dialogs 1</A>
      <UL>
	<LI>
	  <A href="fontinfo.html" >Font Information</A>
	<LI>
	  <SMALL><A href="histogram.html" >&nbsp; &nbsp;Histogram Dialog</A></SMALL>
	<LI>
	  <A href="charinfo.html" >Glyph Information</A>
	<LI>
	  <A href="getinfo.html" >Point, Reference Information</A>
	<LI>
	  <A href="multilayer.html#Layer" >Type3 Layer Information</A>
	<LI>
	  <A href="bdfinfo.html" >Bitmap Properties</A>
	<LI>
	  <A href="baseline.html" >Baseline Information</A>
	<LI>
	  <A HREF="justify.html">Justification Information</A>
	<LI>
	  <A href="math.html" >Math Information</A>
	<LI>
	  <A href="multiplemaster.html" >Multiple Master Information</A>
	<LI>
	    <HR>
	<LI>
	  <A href="lookups.html" >Lookups &amp; subtables</A>
	<LI>
	  <A href="metricsview.html#kernpair" >Kerning glyph pairs 1</A>
	<LI>
	  <A href="kernpairs.html" >Kerning glyph pairs 2</A>
	<LI>
	  <A href="metricsview.html#kernclass" >Kerning by classes</A>
	<LI>
	  <A href="anchorcontrol.html" >Anchor Control</A>
	<LI>
	  <A href="contextchain.html" >Contextual lookup dialog</A>
	<LI>
	  <A href="statemachine.html" >Apple State Machine dialog</A>
	<LI>
	  <A href="showatt.html" >Show Advanced Typography</A>
	<LI>
	    <HR>
	<LI>
	  <A href="problems.html" >Potential Problems dialog</A>
	<LI>
	  <A href="validation.html" >Font Validation dialog</A>
      </UL>
    <LI class="menu">
      <A href="generate.html">Dialogs 2</A>
      <UL>
	<LI>
	  <A href="filemenu.html#Open" >Open Fonts dialog</A>
	<LI>
	  <A href="oflib.html" >Browsing OFLib dialog</A>
	<LI>
	  <A href="generate.html" >Generate Fonts dialog</A>
	<LI>
	  <A href="generate.html#Mac" >Generate Mac Family dialog</A>
	<LI>
	    <HR>
	<LI>
	  <A href="display.html" >Print &amp; Display dialog</A>
	<LI>
	  <A href="prefs.html" >Preferences dialog</A>
	<LI>
	  <A href="groups.html" >Groups dialog</A>
	<LI>
	    <HR>
	<LI>
	  <A href="elementmenu.html#Bitmaps">Manage Bitmap Strikes</A>
	<LI>
	  <A href="elementmenu.html#Regenerate">Re-Rasterize Bitmap Strikes</A>
	<LI>
	    <HR>
	<LI>
	  <A href="search.html" >Search &amp; Replace dialog</A>
	<LI>
	  <A href="Styles.html" >Style Transformation dialogs</A>
	<LI>
	  <A href="transform.html" >Transformation dialog</A>
	<LI>
	  <A href="elementmenu.html#Expand" >Expand Stroke dialog</A>
	<LI>
	  <A href="tilepath.html" >Tile Path dialog</A>
	<LI>
	  <A href="InsertTextDlg.html" >Insert Text dialog</A>
	<LI>
	    <HR>
	<LI>
	  <A href="metricsmenu.html#Width">Set width dialogs</A>
	<LI>
	  <A href="metricsmenu.html#Width">Set left/right bearings</A>
	<LI>
	  <A href="autowidth.html" >Auto Width &amp; Kern dialogs</A>
	<LI>
	    <HR>
	<LI>
	  <A href="hintsmenu.html#Review" >Review PS Hints dialog</A>
	<LI>
	  <A href="ttfinstrs.html" >TrueType Instruction Editor</A>
	<LI>
	  <A href="ttfinstrs.html#cvt" >TrueType 'cvt ' Editor</A>
	<LI>
	    <HR>
	<LI>
	  <A href="selectbyatt.html" >Select by feature dialog</A>
	<LI>
	  <A href="elementmenu.html#MassRename" >Rename Glyphs dialog</A>
	<LI>
	  <A href="elementmenu.html#CompareFonts" >Compare Fonts dialog</A>
      </UL>
    <LI class="menu">
      <A href="filemenu.html">Menus</A>
      <UL>
	<LI>
	  <A href="filemenu.html" >File</A>
	<LI>
	  <A href="editmenu.html" >Edit</A>
	<LI>
	  <A href="pointmenu.html" >Point</A>
	<LI>
	  <A href="elementmenu.html">Element</A>
	<LI>
	  <A href="toolsmenu.html">Tools</A>
	<LI>
	  <A href="hintsmenu.html" >Hints</A>
	<LI>
	  <A href="encodingmenu.html" >Encoding</A>
	<LI>
	  <A href="viewmenu.html" >View</A>
	<LI>
	  <A href="metricsmenu.html" >Metrics</A>
	<LI>
	  <A href="cidmenu.html" >CID</A>
	<LI>
	  <A href="mmmenu.html" >Multi Master</A>
	<LI>
	  <A href="windowmenu.html" >Window</A>
	<LI>
	  <A href="helpmenu.html" >Help</A>
      </UL>
    <LI>
      <A href="faqFS.html">FAQ</A>
    <LI>
      <A href="IndexFS.html">Index</A>
    <LI>
      <A href="GlossaryFS.html">Glossary</A>
    <LI>
      <A href="http://fontforge.wiki.sourceforge.net/">Wiki</A>
  </UL>
</DIV>
<DIV id="in">
  <H1 Align=Center>
    FontForge<BR>
    <SMALL>An Outline Font Editor</SMALL><A HREF="ja/overview.html"><BR>
    <IMG SRC="flags/Nisshoki-Japan.png" WIDTH="39" HEIGHT="26"></A>
  </H1>
  <H2>
    <I><IMG SRC="FontForgeSplash.png" WIDTH="379" HEIGHT="375" ALT="Gaudiamus ligature!"
	ALIGN="Right"></I><A NAME="TOC">Table</A> of Contents
  </H2>
  <UL>
    <LI>
      <A HREF="#Overview">Overview</A>
      <UL>
	<LI>
	  <A HREF="#Installing">Installing</A>
	<LI>
	  <A HREF="#Starting">Starting the program</A>
	<LI>
	  <A HREF="overview.html#What">What is a font editor?</A>
	<LI>
	  <A HREF="#intro">Introductory concepts: fonts, splines, lines, points and
	  paths</A>
	<LI>
	  <A HREF="overview.html#PT">Font Formats</A>
	<LI>
	  <A HREF="#Hints">Hints</A>
	<LI>
	  <A HREF="#References">References</A>
	<LI>
	  <A HREF="#Layers">Layers</A>
	<LI>
	  <A HREF="#Scripts">Scripts</A>
	<LI>
	  <A HREF="overview.html#Glyph-names">Glyph names &amp; Namelists</A>
	<LI>
	  <A HREF="#Lookups">Lookups, Features, Scripts and Languages</A>
	<LI>
	  <A HREF="#Anchors">Anchor Points and Classes</A>
	<LI>
	  <A HREF="#Baseline">Baselines</A>
	<LI>
	  <A HREF="#FontView">Font View</A>
	<LI>
	  <A HREF="#CharView">Outline Glyph View</A>
	<LI>
	  <A HREF="#BitmapView">Bitmap Glyph View</A>
	<LI>
	  <A HREF="#MetricsView">Metrics View</A>
      </UL>
    <LI>
      <A HREF="editexample.html">Example</A>
      <UL>
	<LI>
	  <A HREF="editexample.html">Tutorial</A> &amp; User Guide
	<LI>
	  <A HREF="scriptnotes.html#Special">Special thoughts for special scripts</A>
      </UL>
    <LI>
      <A HREF="fontview.html">Font View</A>
      <UL>
	<LI>
	  <A HREF="fontview.html#Encodings">Encodings</A>
	<LI>
	  <A HREF="fontview.html#Unicode">Unicode</A>
	<LI>
	  <A HREF="fontview.html#CID">CID keyed fonts</A>
	<LI>
	  <A HREF="fontview.html#MM">Multiple Master fonts</A>
	<LI>
	  <A HREF="fontview.html#Vertical-Metrics">Vertical Metrics</A>
      </UL>
    <LI>
      <A HREF="charview.html">Outline Glyph View</A>
      <UL>
	<LI>
	  <A HREF="charview.html#Layers">Layers</A>
	<LI>
	  <A HREF="charview.html#Tools">Tools</A>
	<LI>
	  <A HREF="charview.html#Vertical">Vertical view</A>
	<LI>
	  <A HREF="charview.html#Debugging">Debugging TrueType glyphs</A>
	<LI>
	  <A HREF="charview.html#MM">Multiple Master </A>
      </UL>
    <LI>
      <A HREF="bitmapview.html">Bitmap Glyph View</A>
      <UL>
	<LI>
	  <A HREF="bitmapview.html#Layers">Layers</A>
	<LI>
	  <A HREF="bitmapview.html#Tools">Tools</A>
	<LI>
	  <A HREF="bitmapview.html#AA">Anti-Aliased Glyphs</A>
	<LI>
	  <A HREF="bitmapview.html#Shades">Shades</A>
      </UL>
    <LI>
      <A HREF="metricsview.html">Metrics View</A>
      <UL>
	<LI>
	  <A HREF="metricsview.html#Entering">Entering non-ASCII characters</A>
      </UL>
    <LI>
      <A HREF="hotkeys.html">Hotkeys for Menu commands and other actions</A>
    <LI>
      <A HREF="filemenu.html">Menu Commands</A>
      <UL>
	<LI>
	  <A HREF="filemenu.html">File</A>
	<LI>
	  <A HREF="editmenu.html">Edit</A>
	<LI>
	  <A HREF="pointmenu.html">Points</A>
	<LI>
	  <A HREF="elementmenu.html">Element</A>
	<LI>
	  <A HREF="toolsmenu.html">Tools</A>
	<LI>
	  <A HREF="hintsmenu.html">Hints</A>
	<LI>
	  <A HREF="encodingmenu.html">Encoding</A>
	<LI>
	  <A HREF="viewmenu.html">View</A>
	<LI>
	  <A HREF="metricsmenu.html">Metrics</A>
	<LI>
	  <A HREF="cidmenu.html">CID</A>
	<LI>
	  <A HREF="mmmenu.html">MM</A>
	<LI>
	  <A HREF="windowmenu.html">Window</A>
	<LI>
	  <A HREF="helpmenu.html">Help</A>
	<LI>
	  <A HREF="HotKeys.html">Hot Keys</A>
      </UL>
    <LI>
      <A HREF="scripting.html">Scripting</A>
    <LI>
      Appendices...
      <UL>
	<LI>
	  <A HREF="PfaEdit-TeX.html">Using FontForge with TeX</A>
	<LI>
	  <A HREF="uitranslationnotes.html">Localization</A>
	<LI>
	  <A HREF="errrecovery.html">Error Recovery</A>
	<LI>
	  <A HREF="xres.html">X Resources</A>
	  <UL>
	    <LI>
	      <A HREF="xres.html#Keyboards">Keyboards and Mice</A>
	  </UL>
	<LI>
	  <A HREF="cliargs.html">Command line arguments</A>
	  <UL>
	    <LI>
	      <A HREF="cliargs.html#Environment">Environment Variables</A>
	  </UL>
	<LI>
	  <A HREF="files.html">Files</A>
	<LI>
	  Internals
	  <UL>
	    <LI>
	      <A HREF="src.html">Source file overview</A> (out of date, but goes over the
	      basics)
	    <LI>
	      <A HREF="sfdformat.html">Spline Font Database File Format</A> (also out of
	      date)
	    <LI>
	      <A HREF="plugins.html">Plugins</A>
	    <LI>
	      <A HREF="bezier.html">PostScript &lt;-&gt; TrueType Conversions</A>
	    <LI>
	      <A HREF="corpchar.html">FontForge's use of the Unicode Private Use Area</A>
	  </UL>
	<LI>
	  <A HREF="sfds/index.html">Font samples</A>
      </UL>
    <LI>
      <A HREF="faqFS.html">Frequently Asked Questions</A>
    <LI>
      <A HREF="HotKeys.html">Hot Keys</A>
    <LI>
      <A HREF="GlossaryFS.html">Typographical glossary</A>
    <LI>
      <A HREF="IndexFS.html">Index</A>
    <LI>
      <A HREF="nvd.html">File List</A>
    <LI>
      <A HREF="bibliography.html">Bibliography</A>
    <LI>
      <A HREF="license.html">License and Copyright</A>
    <LI>
      <A HREF="nix-install.html">Download</A>
    <LI>
      <FORM method=GET action="http://www.google.com/search">
	Searching the documentation:
	<INPUT type=hidden name="as_sitesearch" value="fontforge.sourceforge.net">
	<INPUT type=text name="as_q">
	<INPUT type=submit name="btnG" value="Search">(Powered by
	<A HREF="http://www.google.com/">Google</A>)
      </FORM>
  </UL>
  <H2>
    See Also
  </H2>
  <UL>
    <LI>
      <A HREF="sfddiff.html">sfddiff man page</A>
    <LI>
      <A HREF="acorn2sfd.html">acorn2sfd man page</A>
  </UL>
  <P>
  <BLOCKQUOTE ID="lit">
    <TABLE>
      <TR VALIGN="Bottom">
	<TD COLSPAN=2>Eeyore had <A NAME="three-sticks">three</A> sticks on the ground,
	  and was looking at them. Two of the sticks were touching at one end, but
	  not at the other, and the third stick was laid across them. Piglet thought
	  that perhaps it was a Trap of some kind.</TD>
      </TR>
      <TR>
	<TD COLSPAN=2>``Oh, Eeyore,'' he began again, ``just ---''</TD>
      </TR>
      <TR>
	<TD COLSPAN=2>``Is that little Piglet?'' said Eeyore, still looking hard
	  at his sticks.</TD>
      </TR>
      <TR>
	<TD>``Yes, Eeyore, and I---''</TD>
      </TR>
      <TR>
	<TD COLSPAN=2>``Do you know what this is?''</TD>
      </TR>
      <TR>
	<TD COLSPAN=2>``No,'' said Piglet.</TD>
      </TR>
      <TR>
	<TD COLSPAN=2>``It's an A.''</TD>
      </TR>
      <TR VALIGN="Bottom">
	<TD>``Oh,'' said Piglet.</TD>
	<TD ROWSPAN=2><P ALIGN=Right>
	  -- A. A. Milne, 1928<BR>
	  The House At Pooh Corner</TD>
      </TR>
      <TR>
	<TD>``Not O, A,'' said Eeyore severely.</TD>
      </TR>
    </TABLE>
  </BLOCKQUOTE>
  <P>
  Font design can be a Trap, but I find it a rather pleasant one. <EM>Caveat
  utor</EM>.
  <H2>
    <A NAME="Overview">Overview</A>
  </H2>
  <P>
  FontForge allows you to create and modify postscript, truetype and opentype
  fonts. You can save fonts in many different outline formats, and generate
  bitmaps.
  <H3>
    <A NAME="Installing">Installing</A> or building fontforge
  </H3>
  <TABLE CELLSPACING="6" CELLPADDING="2">
    <CAPTION>
      System specific install procedures
    </CAPTION>
    <TR>
      <TD><P ALIGN=Center>
	<A HREF="nix-install.html">Unix/Linux</A></TD>
      <TD>&nbsp; &nbsp; &nbsp; <A HREF="mac-install.html">Mac</A></TD>
      <TD>&nbsp; &nbsp; &nbsp; <A HREF="ms-install.html">MS/Windows</A></TD>
      <TD>&nbsp; &nbsp; &nbsp; <A HREF="vms-install.html">VMS</A></TD>
      <TD>&nbsp; &nbsp; &nbsp; <A HREF="source-build.html">from source</A></TD>
      <TD>&nbsp; &nbsp; &nbsp; <A HREF="uninstall.html">Uninstalling</A></TD>
    </TR>
  </TABLE>
  <P>
  <A HREF="running.html">Running fontforge</A>
  <H3>
    Er... <A NAME="What">What</A> is a font editor?
  </H3>
  <P>
  A font editor is a progam designed to creat and modify fonts.
  <P>
  The most obvious aspect is that it is a drawing program like FreeHand, Inkscape
  or Illustrator which lets you draw the outlines of your letters. Unlike other
  drawing progams it expects you to draw many pictures at once (one or more
  for each letter) and collects them into a database.
  <P>
  It allows you to describe the way these pictures interact with each other
  (if you put one picture after the other then they should normally be separated
  by a certain distance -- the font's metrics, or if these two pictures are
  placed adjacent to one another then they turn into a third -- the font's
  ligatures, and so on).
  <P>
  Finally a font editor will bundle up all the pictures you have drawn, and
  all the metadata about how those pictures fit together, and will turn that
  bundle of stuff into a font that your computer can use to display text.
  <H3>
    <A NAME="intro">Introductory</A> concepts: Fonts, Splines, Lines, Points,
    Paths and the em-unit
  </H3>
  <P>
  Most simply a font is a collection of glyphs. But computer fonts must contain
  more than this, at the least they must also contain information on how to
  map an input string of bytes into an output display of visual glyphs. This
  mapping is called an encoding. Many fonts will also contain rules for how
  adjacent glyphs should be arranged. For instance, in fonts for the latin
  alphabet, there is often a rule saying that if "f" and "i" are adjacent then
  a special glyph, a ligature of "f" and "i" should be used instead. Fonts
  for latin letters generally do not require such rules (but can be enhanced
  by them), fonts for other scripts like arabic require them.
  <P>
  What's the difference between a character and a glyph?
  <P>
  A character is a concept and a glyph is a reification of that concept. The
  letter "A" is a character, while<IMG SRC="As.png" WIDTH="220" HEIGHT="33">
  are all glyphs that represent an "A". In latin fonts there is often a single
  glyph for every character and a single character for every glyph, but not
  always -- in renaissance printing there were two glyphs for a lower-case
  s, <IMG SRC="short-long-s.png" WIDTH="17" HEIGHT="12">the short and the long
  s. Whereas a ligature is an example of a glyph that represents two (or more)
  characters. In arabic most of the letters (characters) have at least four
  different glyphs, the appropriate glyph being determined by the letters around
  it. Here are four forms of the arabic character "seen"
  <IMG SRC="arabic-seen.png" WIDTH="108" HEIGHT="17" ALIGN="Middle">.
  <P>
  What is an outline font? What is a bitmap font?
  <P>
  Each glyph in a font has a shape and there are various ways of describing
  that shape on a computer. PostScript and truetype fonts generally describe
  the outline of the shape and then color in the interior of that outline,
  this coloring process is called rasterizing. On the other hand a bitmap font
  describes each glyph by drawing a picture of that character on a rectangular
  grid of pixels. There is a third type, a stroked font, where each stem of
  the glyph is represented by one line down the center of the stem, and the
  line is later drawn with a certain width. Most of the time we will not deal
  with stroked fonts directly (the <A HREF="elementmenu.html#Expand">Expand
  Stroke</A> command can be used to turn them into outlines), but if you wish
  to edit stroked fonts, see the section on
  <A HREF="multilayer.html">multi-layered editing</A>.
  <TABLE BORDER CELLPADDING="2">
    <TR VALIGN=Top>
      <TD><P ALIGN=Center>
	<I><IMG WIDTH="117" HEIGHT="201" SRC="outlinechar.png"></I><BR>
	A glyph's outline</TD>
      <TD><P ALIGN=Center>
	<IMG SRC="bitmapchar.png" WIDTH="117" HEIGHT="201"><BR>
	A glyph's bitmap</TD>
      <TD><P ALIGN=Center>
	<IMG SRC="strokechar.png" WIDTH="208" HEIGHT="198"><BR>
	A stroked glyph<BR>
	(showing the equiv. outline in grey)</TD>
    </TR>
  </TABLE>
  <P>
  An outline is composed of a set of contours or paths. In the picture on the
  above left the letter A is described by three different paths. The main one
  is on the outside and the two smaller ones are internal. Each of these paths
  is composed of a series of (B&eacute;zier) splines and line segments. FontForge
  can handle cubic and quadratic splines. PostScript fonts use cubic splines,
  TrueType fonts use quadratic (SVG fonts can be either).
  <P>
  Each cubic <A NAME="spline">spline</A> is defined by four points, two of
  which mark the end points of the spline and two more to describe the slope
  of the spline at those end points. Here are <A HREF="bezier.html">two cubic
  splines</A> with all their points shown:
  <P>
  <IMG SRC="splines.gif" WIDTH="172" HEIGHT="179" ALIGN="Left">
  <P>
  The points which describe the slope are called control points. They are
  represented here (and in fontforge) by little colored x's. Moving a control
  point will change the shape of the spline, but it will not alter where the
  spline begins or ends.
  <P>
  <IMG SRC="pnts.gif" WIDTH="169" HEIGHT="165" ALIGN="Right">A series of splines
  and lines are joined together to make a path. There are several possible
  ways to make these joins as is shown in the example to the right. In each
  case we have three points in approximately the same relative positions. The
  three points are joined by splines or lines, but the type of joins alters
  the appearance of the connections.
  <P>
  In the first case there are no control points and the result is two straight
  lines, in the second case there is a line and a curved spline which are tangent
  at their point of intersection, in the third case there are two splines which
  are again tangent at their point of intersection. The point of intersection
  in the first case is called a corner point, and the incoming and outgoing
  splines or lines may be in any orientation with respect to each other. This
  is represented in fontforge by a square box. In the second case the point
  of intersection is called a tangent point, it is represented by a triangle.
  The third case is a curved point and is represented by a circle.
  <P>
  <IMG SRC="quadraticspline.gif" WIDTH="127" HEIGHT="92" ALIGN="Left">FontForge
  can also edit <A NAME="quadratic">quadratic</A> splines (the splines used
  in truetype fonts), here there is only one control point and it controls
  the slopes at both end-points. Because of this quadratic splines cannot bend
  in as many ways as cubic splines (the first spline above left would need
  at least two quadratic splines to draw), and you will often need more splines
  to achieve the same curve. You can control whether a font contains cubic
  or quadratic splines with the
  <A HREF="fontinfo.html#PS-General">Element-&gt;Font Info </A>command.
  <P>
  There are many different types of splines in the world. The ones described
  above are B&eacute;ziers -- these are numerically simple and have a number
  of nice properties -- which is why they are used internally in fonts. However,
  there are some even nicer splines. It is easy to give B&eacute;zier splines
  the same slope on either side of a point, but a curve will look much nicer
  if it has the same curvature on either side of a point. Clothoid splines
  have this property.
  <P>
  <A HREF="http://www.levien.com/">Raph Levien </A>has kindly donated to the
  open source community a <A HREF="http://libspiro.sf.net/">library</A> for
  converting clothoid splines into B&eacute;ziers.
  <P>
  Clothoid splines are much easier to work with than B&eacute;ziers -- there
  are no control points, just a sequence of on-curve points, and magically
  a beautiful curve will appear between them. FontForge can
  <A HREF="charview.html#spiro-mode">either</A> edit a curve as a set of
  B&eacute;ziers or as a set of clothoids.
  <P>
  A path is closed when it comes back and joins its start. All paths in an
  outline font should be closed. Once a path is closed in may be said to have
  a direction, essentially this may be thought of as "Was the path created
  in a clockwise or a counter-clockwise fashion?" (this is actually a little
  simplistic, if a path intersects itself, as in a figure 8, then the direction
  cannot be described as either clockwise or counter-clockwise, but most paths
  do not self-intersect (and paths in a font <STRONG>SHOULD NOT
  </STRONG>self-intersect) and we will simplify our life by pretending that
  we can call paths clockwise or counter).
  <P>
  When time comes to draw our outline glyph we want to make dark everything
  in the interior of the outline. But let's look at the outline of our A above.
  We have two paths inside the main outline path, and we want the interior
  of those two paths to be white rather than dark. How do we make this distinction?
  We do it by the direction of the paths. Consider any point in the glyph.
  If we draw an imaginary line from that point out to infinity (in any direction)
  and count the number of times we cross a path, each time we cross a clockwise
  path we add one to our count, each time we cross a counter clockwise path
  we subtract one. If the result of our count is non-zero then we color the
  point dark, otherwise we leave it white. So to make the A above work we make
  the outer path be clockwise and the two inner ones be counter-clockwise (Things
  could be done the other way around, but the convention is that the outer
  path should be clockwise).
  <P>
  All of these points (both the end points and the control points) are described
  mathematically. Each point is positioned on a cartesian coordinate system
  which has its origin on the glyph's <A HREF="#Baseline">baseline</A> (the
  line on which letters without descenders rest). Most font formats expect
  coordinates to be integers between -32768 and 32767, FontForge uses real
  numbers internally but (usually) rounds to the nearest integer when generating
  a font file.
  <P>
  Generally it is a good idea to restrict yourself to integral coordinates.
  TrueType fonts can only contain integral coordinates so if you use a non-integral
  value FontForge will be forced to round it to an integer and this will alter
  the shape of the curve. PostScript fonts can contain non-integral values,
  but the various formats are optimized for integers. So use integers when
  you can. If you need more precision you can increase the "em-size" of the
  font.
  <P>
  When displaying a font we use the word "<A NAME="em-unit">em</A>" to represent
  the size of the font. If a font is displayed at 12points then 1em will be
  12points. If the font is displayed at 18points then an em will be 18points.
  (traditionally a 12 point font is one where the metal slugs are 12 points
  tall -- or where the baseline to baseline spacing of unleaded text is 12
  points, so an em was the size of the metal.).
  <P>
  When designing an outline font, you can no longer think in terms of points
  -- these fonts are scalable and can be any pointsize. You must think in terms
  of the em and fractions of the em. When you create a font you choose how
  many internal units (called "em-units") to use to represent 1 em -- this
  number is called the "em-size". In most PostScript fonts there are 1000 units
  to the em, TrueType fonts often have either 1024 or 2048 units to the em
  (TrueType recommends that you use a power of two). But you can choose any
  (positive) number you like (well, as long as it is less than 32767), the
  numbers above are conventions not requirements).
  <P>
  Suppose you have a dash in a PostScript font, and that dash is 500 units
  long, and the font has 1000 units to the em. Suppose a someone displays that
  dash at 12 points. Then that dash will be drawn with a length of 500/1000
  * 12 = 6 points. On a 72 dot per inch screen where a pixel is almost exactly
  one point, the dash will be 6 pixels long.
  <P>
  <IMG SRC="sidebearings.png" WIDTH="111" HEIGHT="191" ALIGN="Right">Every
  glyph has its own co&ouml;rdinate system. The font's
  <A HREF="#Baseline">baseline</A> (the line upon which most latin glyphs will
  rest) is 0 in the vertical direction. The horizontal origin is where the
  glyph will start being drawn (what is "drawn" will usually be empty space
  for a short while -- as there is usually some space between the origin and
  the edge of the glyph). This horizontal distance between the origin and the
  leftmost edge of the glyph is called the left side bearing (it may be negative,
  positive or zero). All glyphs have a width (sometimes called an advance width),
  this is the distance from the origin of the current glyph to the origin of
  the next. The distance between the right edge of the glyph and the width
  is called the right side bearing.
  <P>
  CJK text (Chinese, Japanese or Korean) can be written either vertically or
  horizontally, and so CJK fonts usually have a vertical advance width as well
  as the more common horizontal advance (and concomittant top and bottom side
  bearings).
  <P>
  A glyph like "g" or "y" extends below the baseline, this is called a descender,
  while a glyph like "k" or "l" extends above the x-height, this is called
  an ascender. Most latin (and greek and cyrillic) fonts have certain standard
  heights: the height of a lower case letter (without an ascender) is called
  the x-height, the height of a capital letter is called the cap-height, the
  height of the ascenders is called the ascender height (some, but not all,
  fonts have the ascenders and capitals at the same approximate height). Often
  these will not be exactly the same for all glyphs, the letter "O" is usually
  slightly taller than the letter "I", but they both are within the range of
  the cap height for the font.
  <P>
  The font itself has an ascent and descent associated with it. In the old
  days of metal type nothing could ascend above or descend below these values,
  nowadays accents and ascenders may reach above the font-wide ascent and
  descenders below the descent, but the concept is still a convenient one to
  retain. It is true that in almost all cases the glyphs will not ascend above
  or descend below the font-wide ascent and descent. The sum of the ascent
  and descent is the size of the font. The point size of a piece of metal type
  was determined by this value (essentially the height of the metal block holding
  the glyph). In a postscript font the local coordinate system is independent
  of the final size at which the font will be drawn.
  <H3>
    <A NAME="PT">TrueType</A> vs. PostScript vs OpenType vs SVG fonts
  </H3>
  <P>
  FontForge can produce many font types. What's the difference?
  <P>
  PostScript is based on a <A HREF="bezier.html">cubic spline</A> technology,
  while TrueType is based on a <A HREF="bezier.html">quadratic</A> technology.
  Cubic splines are generally easier to edit (more shapes are possible with
  them). Any quadratic spline can be converted to a cubic spline with essentially
  no loss. A cubic spline can be converted to a quadratic with arbitrary precision,
  but there will be a slight loss of accuracy in most cases.
  <P>
  Within FontForge a font may contain either cubic or quadratic splines. These
  are converted to the appropriate format when a font is generated.
  <P>
  The other major difference between the two is how they solve the problem
  of drawing nice images at small pointsizes. PostScript calls this "Hinting",
  while TrueType calls it "Instructing" a font.
  <H4>
    What's OpenType?
  </H4>
  <P>
  Unfortunately the word "OpenType" has come to have several meanings.
  <P>
  The first meaning describes the glyph (and spline) format of the font. In
  this sense Open Type is just a postscript font put into a truetype file format
  -- From the outside it looks like a truetype font except that the outline
  descriptions are postscript Type2 font descriptions rather than TrueType.
  Technically it is a <A HREF="glossary.html#CFF">CFF</A> font inside an
  <A HREF="glossary.html#SFNT">sfnt</A> wrapper.
  <P>
  In a second sense of the word OpenType refers to a set of tables containing
  advanced typographic information. These tables may be added to either fonts
  specified with quadratic splines (truetype) or fonts with cubic splines.
  <P>
  Finally MS Windows uses an OpenType icon for a font if that font contains
  a 'DSIG' (Digital Signature) table.
  <P>
  To make things even more confusing the OpenType specification includes the
  old TrueType specification, so technically any TrueType font can be called
  an OpenType font.
  <P>
  FontForge does not support the DSIG table (if you want one there is a free
  tool from MS which will add one). When generating a font, FontForge uses
  the term "OpenType (CFF)" to represent a PostScript (CFF) font inside an
  sfont wrapper. To include OpenType typography tables you would press the
  <CODE>[Options] </CODE>button and select the <CODE>[] OpenType</CODE> check
  box.
  <H4>
    What's SVG?
  </H4>
  <P>
  SVG (Scalable Vector Graphics) provides a relatively new font format, written
  in an xml dialect. SVG fonts can be either cubic or quadratic (or can use
  both, but FontForge is limited and will force a font to be either all cubic
  or all quadratic). SVG allows for two different types of fonts, one corresponds
  roughly to PostScript Type1 fonts, and the other, roughly to PostScript Type3
  fonts.
  <H4>
    What are Type3 fonts?
  </H4>
  <P>
  Back in the early days of PostScript, the Type1 format was proprietary, only
  Adobe could make Type1 fonts, but anyone could make Type3 fonts. Type3 fonts
  were unhinted, but could include any postscript command and so could produce
  a wider range of pictures (multi-colored glyphs, stroked glyphs, glyphs based
  on scaled images, etc.). Most of the time these extensions are unnecessary,
  and the disadvantage of being unhinted is onerous -- but sometimes you want
  to play.
  <H4>
    What are Type1 fonts?
  </H4>
  <P>
  These were the standard stand-alone PostScript fonts of the '80s and '90s.
  <H4>
    What are Type2 fonts?
  </H4>
  <P>
  These use a slightly different internal format (a more compact one) to express
  the same information as type1. This is the format that lives inside a CFF
  font which lives inside an OpenType font.
  <H4>
    What are CFF fonts?
  </H4>
  <P>
  This is the font format that is designed to store PostScript Type2 information.
  It is most commonly found inside an OpenType (PostScript) font.
  <H4>
    What is Apple Advanced Typography?
  </H4>
  <P>
  This is another way of specifying typographic information (like ligatures,
  kerning, glyph substitutions). It appeared before OpenType and is only used
  on Apple computers. It is based on state machines and is a little harder
  to work with than OpenType.
  <H3>
    <A NAME="Hints">Hints</A>
  </H3>
  <P>
  At small pixel sizes, the process of drawing the interior of an outline font
  is quite difficult to do well. PostScript and TrueType have different approaches
  to the problem of providing extra information to the rasterizer about how
  to draw small fonts.
  <TABLE BORDER CELLPADDING="2" ALIGN="Center">
    <CAPTION>
      <SMALL>Rasterization improvements<BR>
      from hinting TrueType.<BR>
      18pt font rasterized by Windows<BR>
      (scaled by a factor of 2)</SMALL>
    </CAPTION>
    <TR>
      <TD><P ALIGN=Center>
	&nbsp;&nbsp;<IMG SRC="HI.nohints.png" WIDTH="44" HEIGHT="28">&nbsp;&nbsp;<BR>
	no hints</TD>
      <TD><P ALIGN=Center>
	&nbsp;&nbsp;<IMG SRC="HI.hints.png" WIDTH="44" HEIGHT="28">&nbsp;&nbsp;<BR>
	hints</TD>
    </TR>
  </TABLE>
  <DL>
    <DT>
      <H4>
	PostScript
      </H4>
    <DD>
      Adobe incorporated several different ways of providing hints for the rasterizer
      about how things should be treated. The most obvious of these are the horizontal
      and vertical stem hints. Each glyph has its own set of hints to tell the
      rasterizer where to find stems. FontForge can usually figure out a reasonable
      set of stem hints (a process called
      <A HREF="hintsmenu.html#AutoHint">autohinting</A>), but some glyphs are too
      complex for it and it can make bad choices. It also provides a mode for you
      to override its choices.
      <P>
      Adobe also has a mechanism for handling dished serifs called flex hinting.
      This means a curve that is only slightly deformed from the horizontal (or
      vertical) will display as a line at small point sizes and as a curve at larger
      ones. FontForge will use these when it seems appropriate.
      <P>
      The original version of hints did not allow them to overlap, this meant that
      most serifs could not be described, Adobe then developed a mechanism called
      hint substitution which allows for different sets of non-overlapping hints
      to exist in different parts of the glyph. There are still shapes which cannot
      be fully hinted, but hint substitution is an improvement. The
      Hints-&gt;AutoHint command will figure out what stems overlap and where to
      change the current set of hints. The Hints-&gt;Hint Substitution Pts command
      will also figure where hint changes should occur, and the Hint Mask pane
      of the Point Info dialog gives the user direct control over this.
      <P>
      Most recently Adobe has provide a means to control the counters, the spaces
      between stems, in a glyph. The original Type1 description provided support
      for the horizontal counters in "m" and the vertical counters in "E" but more
      complex shapes could not be dealt with. Counter Hints (in a type1 font) may
      only be used with non-latin (non-greek, non-cyrillic) glyph sets, in type2
      (OpenType) things are a bit more complicated,. FontForge will generate counter
      hints when appropriate.
      <P>
      Adobe provides some font-wide hinting mechanisms. The two most obvious are
      the BlueValues and StemSnap settings in the
      <A HREF="fontinfo.html#Private">private dictionary</A>. BlueValues provides
      a list of vertical zones in which interesting things happen (so in a latin
      font this might include the ascender height, the cap-height, the x-height,
      the baseline and the descender height. At small point sizes everything within
      one of these zones will snap to the same height, while at larger point sizes
      the heights will be slightly different (for instance an "o" and an "x" usually
      have slightly different heights, but displaying that at a small point size
      would be ugly). Similarly the StemSnap variables specify standard stem widths
      for the font. FontForge will try to guess reasonable values for these. It
      also allows you to override these guesses and
      <A HREF="fontinfo.html#Private">specify your own values</A>. For a more
      comprehensible description of the private dictionary and what it can do,
      look at
      <A HREF="http://partners.adobe.com/asn/developer/PDFS/TN/T1_SPEC.PDF">Adobe's
      Type1 font specification</A>.<BR>
      <A NAME="HintOrder">FontForge</A>'s
      <A HREF="hintsmenu.html#AutoHint">AutoHint</A> command will work better if
      the BlueValues have been set. So before running AutoHint go to
      <A HREF="fontinfo.html#Private">Element-&gt; FontInfo-&gt; Private</A> to
      set this array. After AutoHinting you should regenerate the StemSnaps (also
      at Element-&gt; FontInfo-&gt; Private).
    <DT>
      <H4>
	<A NAME="TrueType">True</A> Type
      </H4>
    <DD>
      <TABLE ALIGN=Right>
	<TR>
	  <TD ALIGN=Center><IMG SRC="GridFitM.png" WIDTH="246" HEIGHT="241"><BR>
	    Grid Fit M</TD>
	</TR>
      </TABLE>
      <P>
      On the other hand, True Type says that figuring out what pixels to turn on
      would be a lot simpler if only the points and the splines were in the right
      place (ie. at pixel boundaries). And so True Type provides a set of instructions
      that move points around until they are positioned appropriately for a given
      size.
      <P>
      FontForge's hinting of True Type (properly called "instructing") is based
      on the stem hints also used by PostScript and on diagonal hints. It uses
      these hints to determine which points to move and where to move them.
      <P>
      When FontForge reads in a TrueType font it will store the instructions used,
      and when it next generates that font it will use those instructions -- provided
      no significant change has happened to a glyph.
  </DL>
  <P>
  Most of my <A HREF="hinting.html">hinting user interface</A> is designed
  with PostScript fonts in mind.
  <H3>
    <A NAME="References">References</A>
  </H3>
  <P>
  In addition to a set of outlines (splines) glyphs may be built out of references
  to other glyphs. This is especially handy for the accented glyphs, "&agrave;"
  can be made up of a reference to the "a" glyph and another reference to the
  "`" glyph. This can result in significant space savings, and in ease of design
  (if you change the "a" glyph after making a reference to it the "&agrave;"
  glyph will automatically change too, whereas if you just copied the "a" you
  would have to recopy it.
  <P>
  FontForge has three commands for manipulating references, and one higher
  level command for building accented glyphs. The
  <CODE><A HREF="editmenu.html#Reference">Edit-&gt;Copy Reference</A></CODE>
  command will put a reference to the current glyph into the clipboard, which
  a subsequent
  <CODE><A HREF="editmenu.html#Paste">Edit-&gt;Paste</A></CODE> command will
  install as a reference. The
  <CODE><A HREF="editmenu.html#Unlink">Edit-&gt;Unlink Reference</A>
  </CODE>command will turn a reference in a glyph into it's component splines.
  The <CODE><A HREF="elementmenu.html#Info">Element-&gt;Get Info</A>
  </CODE>command (when applied to a reference) will bring up a dialog showing
  you what glyph is referred to, and allowing you to bring up an editing window
  on that glyph. Finally the
  <CODE><A HREF="elementmenu.html#Accented">Element-&gt;Build-&gt;Accented
  Glyphs</A></CODE> command will figure out what glyphs should be refered to
  to build this composite glyph, and then will make those references and position
  them appropriately. So if "&agrave;" were selected and you did a
  <A HREF="elementmenu.html#Accented"><CODE>Element-&gt;Build-&gt;Accented
  Glyphs</CODE> </A>command, FontForge would make a reference to "a" and another
  to "`", and place the accent above the letter, and centered on it.
  <P>
  Some bitmap formats (OK, only one that I'm aware of) support references,
  so FontForge allows references in bitmap glyphs as well as in outline glyphs.
  <P>
  Sadly life is not always that simple. The references FontForge uses internally
  cannot always be converted into something equivalent in the output font.
  Generally this causes no problems (FontForge will simply unlink the reference
  in the output, which just makes the font a little bigger, but it has implications
  for instructing TrueType, and, to a lesser extent, hinting PostScript. Most
  people can ignore this, but if you are interested
  <A HREF="ref-caveats.html">follow this link</A>).
  <P>
  Most font formats require that a glyph contain either a set of outlines (or
  bitmap rasters) or a set of references. FontForge allows glyphs with a
  combination of the two, but, as above, when it comes time to output the results,
  FontForge will clean up the glyph (generally by unlinking references) so
  that it can be output in the current format.
  <H3>
    <A NAME="Layers">Layers</A>
  </H3>
  <P>
  A font may have several layers. When FontForge creates a new font it will
  have 2 real layers (the foreground and background layers) and a sort of
  half-layer for guidelines which is shared by all glyphs. In normal fonts
  all glyphs have the same number of layers (This is not true of Type3 fonts,
  and <A HREF="#Type3">I'll talk about them later.</A>)
  <P>
  Both the foreground layer and the background layer have certain predefined
  meanings: The foreground layer is the default layer for dialogs where there
  is no clear way to specify a layer. The background layer can contain all
  sorts of stuff, basically whatever you want it to, but any images in it may
  be autotraced into the foreground layer.
  <P>
  You may add other layers with the
  <CODE><A HREF="fontinfo.html#Layers">Element-&gt;Font Info-&gt;Layers
  </A></CODE>pane. Each layer may have a name and a different kind of splines
  (quadratic or cubic).
  <P>
  One potential use of addtional layers: Many people find it easier to edit
  using cubic splines but like to produce truetype fonts with quadratic splines.
  You can use one layer to hold the cubic splines and another to hold the
  quadratics. There are commands for comparing layers
  (<CODE><A HREF="elementmenu.html#CompareL2L">Element-&gt;Compare Layer To
  Layer</A></CODE>) and others for copying one layer to another (and adjusting
  the splines to fit the new layer:
  <CODE><A HREF="editmenu.html#CopyL2L">Edit-&gt;Copy Layer To
  Layer</A></CODE>).
  <P>
  It seems a shame to have both a valid cubic and a valid quadratic font in
  a database and only be able to produce a font from one of them, so the font
  view will allow you to switch between layers
  (<CODE><A HREF="viewmenu.html#FVLayers">View-&gt;Layers-&gt;*</A></CODE>)
  and <CODE><A HREF="generate.html">File-&gt;Generate Fonts</A> </CODE>command
  will allow you to output whatever layer you want into the font. (Note that
  all layers will share the same hints, instructions, character set, bitmaps,
  etc. It is only the outlines which differ.) Furthermore, you may choose to
  store all the layers of a font into an sfnt (TrueType / OpenType font) with
  the <A HREF="generate.html#Options"><CODE>[]Layers</CODE> checkbox of the
  PfaEdit table of the <CODE>[Options]</CODE></A><CODE> </CODE>dialog.
  <H4>
    <A NAME="Type3">Type3 Fonts</A>
  </H4>
  <P>
  Most people aren't interested in editing <A HREF="multilayer.html">Type3
  PostScript fonts </A>(nor the equivalent SVG font), but if you want to, FontForge
  can. Here
  each layer represents a different drawing operation, and may specify a different
  color, stroke, fill, etc. Layers are not font-wide, each glyph has its own
  set of layers (which are not named). You can
  <A HREF="multilayer.html#Layer">create new layers with a popup menu </A>in
  the layers pane of the outline view.
  <H4>
    Guidelines
  </H4>
  <P>
  In FontForge guidelines live in their own mini-layer (it isn't a full layer
  because all glyphs share the same set of guidelines rather than having an
  individual layer for each glyph). It can be edited just like any other layer
  and you may have guidelines of any shape you desire. You may also drag out
  horizontal and vertical guidelines from the edges of the outline glyph view.
  <H3>
    <A NAME="Scripts">Scripts</A>
  </H3>
  <P>
  A script is a collection of letter shapes and rules for putting letters together.
  For instance the latin script consists of the letters A-Z, written left to
  right, along with a transformation from upper to lower case, a few ligatures
  and rules for generating accents. Arabic is a script consisting of its own
  character set, written right to left, along with transformations for initial,
  medial, final and isolated forms, many ligatures and rules for placing vowel
  marks.
  <H3>
    <A NAME="Glyph-names">Glyph names &amp; Namelists</A>
  </H3>
  <P>
  Within fontforge every glyph will have a name. Generally the glyph name will
  be something that provides information about what the glyph looks like so
  the name for the glyph representing "9" is "nine". Adobe has established
  a
  <A HREF="http://partners.adobe.com/public/developer/en/opentype/aglfn13.txt">standard
  for what names may be assigned to what glyphs</A>, and when producing a font
  for general use it is best to stick to that standard (Acrobat uses the glyph
  names and recognizes the standard ones. If you try and use "neuf" for "nine"
  Acrobat will not recognize it and surprising things will fail).
  <P>
  Adobe's standard provides reasonably mnemonic names for most latin and greek
  glyphs (to English speakers anyway), some rather incomprehensible names for
  cyrillic and hebrew (afiiXXXXX) and identifies most other glyphs by unicode
  code point (uniXXXX or uXXXXX where "X" represents a hex digit and XXXX is
  the unicode code point in hex).
  <P>
  If you are an english speaker and you are working with latin glyphs this
  is fine and dandy. But if you are French you might wish that "adieresis"
  were named "atr&eacute;ma" -- for that matter even if you are an English
  speaker you might prefer it to be named "aumlaut". No matter who you are
  you might prefer more mnemonic names for the code block you are working on.
  <P>
  FontForge has a concept called a
  <A HREF="encodingmenu.html#namelist">namelist</A>, each of which is simply
  a mapping from unicode code point to name. Several namelists may be defined,
  different lists may apply to different fonts and a font may have all its
  glyphs renamed from one namelist to another.
  <P>
  Namelists can also help navigating in a font. Even if a list does not apply
  to a given font its names may be used in the goto dialog to find glyphs.
  So if you've loaded a french namelist you can search for "atr&eacute;ma"
  and FontForge will show you the glyph "adieresis" or "uni00E4" or "aumlaut"
  or whatever.
  <P>
  A few caveats: Adobe's glyph name standard expects all glyph names to be
  in ASCII characters. Syntactically postscript permits a wider range of glyph
  names, but if you use non-ASCII characters some rasterizers might have problems.
  Best to keep non-ASCII names within fontforge (and rename glyphs to adobe's
  standard names before generating a font).
  <H3>
    <A NAME="Lookups">Lookups,</A> Features, Scripts and Languages
  </H3>
  <P>
  OpenType (and Apple Advanced Typography) allow various transformations to
  be applied to the input glyph stream to produce an output glyph stream. These
  transformations might include forming ligatures, kerning glyphs closer to
  each other, attaching vowel marks or diacritics to letters, conditionally
  replacing one glyph with another depending on the glyphs around it, etc.
  <P>
  The commands for each transformation are stored in what are called lookups.
  If you were designing a set of lookups to handle latin ligatures, you might
  have one lookup for ff, fl and ffl -- ligatures that happen almost all the
  time, another for fi and ffi -- ligatures which don't happen in Turkish but
  do in other languages, and lookups for ct and st -- ligatures which rarely
  happen in English but are more frequent in German (I think).
  <P>
  A Feature is a tagged collection of lookups. The tags are all 4 letter sequences
  (like 'liga') with standardized meanings. The 'liga' tag means standard
  ligatures. The 'dlig' tag means discretionary ligatures, and 'kern' means
  kerning. There are many others.
  <P>
  Every script (latin, cyrillic, han ideographs, ...) will have its own set
  of features that are meaningful to it. Sometimes things will be even more
  complicated, and each language within a script will have it's own set of
  features. In the example above we might assign scripts, languages, features
  and lookups thusly:
  <TABLE BORDER CELLPADDING="2">
    <TR>
      <TH>Script</TH>
      <TH>Language</TH>
      <TH>Feature</TH>
      <TH>Lookups</TH>
      <TH>Comments</TH>
    </TR>
    <TR>
      <TD ROWSPAN=7>latn</TD>
      <TD ROWSPAN=3>default</TD>
      <TD ROWSPAN=2>liga (standard)</TD>
      <TD>lookup for ff, fl and ffl</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>lookup for fi and ffi</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>dlig (discretionary)</TD>
      <TD>lookup for ct and st</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>Turkish</TD>
      <TD>liga</TD>
      <TD>lookup for ff, fl and ffl</TD>
      <TD>Lookups may be shared, so this can be the same lookup as above<BR>
	(Turkish distinguishes between i and dotlessi and fi ligatures hide this
	distinction.)</TD>
    </TR>
    <TR>
      <TD ROWSPAN=3>German</TD>
      <TD ROWSPAN=3>liga</TD>
      <TD>lookup for ff, fl and ffl</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>lookup for fi and ffi</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>lookup for ct and st</TD>
      <TD>Lookups may even be shared by a different feature type, so for English
	and Spanish ct might count as a discretionary ligature, one rarely used,
	while in German it mght be more common and be part of the standard ligature
	set.</TD>
    </TR>
  </TABLE>
  <P>
  The default language means any language in the script which is not specifically
  named. So in the above example the default language would be any language
  except Turkish and German that might use the latin script.
  <P>
  It is also possible to have a default script. The digits 0-9, are used in
  many writing systems, not just Latin and are considered Common to most scripts.
  If you have lookups which apply to the digits (conversion to oldstyle digits,
  or to proportional digits, or to superscripts...) you should attach those
  lookups to features in all scripts (and languages) that could use them, and
  to the default script (just in case).
  <TABLE BORDER CELLPADDING="2">
    <TR>
      <TH>Script</TH>
      <TH>Language</TH>
      <TH>Feature</TH>
      <TH>Lookups</TH>
      <TH>Comments</TH>
    </TR>
    <TR>
      <TD ROWSPAN=9>latn</TD>
      <TD ROWSPAN=3>default</TD>
      <TD>pnum</TD>
      <TD>proportional number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>onum</TD>
      <TD>old style number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>subs</TD>
      <TD>subscript lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD ROWSPAN=3>Turkish</TD>
      <TD>pnum</TD>
      <TD>proportional number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>onum</TD>
      <TD>old style number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>subs</TD>
      <TD>subscript lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD ROWSPAN=3>German</TD>
      <TD>pnum</TD>
      <TD>proportional number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>onum</TD>
      <TD>old style number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>subs</TD>
      <TD>subscript lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD ROWSPAN=3>cyrl</TD>
      <TD ROWSPAN=3>default</TD>
      <TD>pnum</TD>
      <TD>proportional number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>onum</TD>
      <TD>old style number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>subs</TD>
      <TD>subscript lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD ROWSPAN=3>DFLT</TD>
      <TD ROWSPAN=3>default</TD>
      <TD>pnum</TD>
      <TD>proportional number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>onum</TD>
      <TD>old style number lookup</TD>
      <TD></TD>
    </TR>
    <TR>
      <TD>subs</TD>
      <TD>subscript lookup</TD>
      <TD></TD>
    </TR>
  </TABLE>
  <P>
  There are roughly 15 different types of lookups which contain different
  information. Different kinds of lookup are needed to specify ligature data,
  glyph substitution data and kerning data.
  <P>
  Lookups may be specified with the
  <A HREF="fontinfo.html#Lookups">Element-&gt;Font Info</A> dialog
  <H4>
    Lookup subtables
  </H4>
  <P>
  I talk above about lookups as if they were simple things. Unfortunately they
  aren't. Each lookup is composed of "Subtables" which actually do the work.
  <P>
  A lookup may contain several subtables. Most contain exactly one. (If a lookup
  contains no subtables it will do nothing).
  <P>
  I said there were about 15 kinds of lookup, there are even more kinds of
  subtable. For instance a subtable which specifies glyph to glyph kerning
  is different from one which specifies glyph class to glyph class kerning.
  <P>
  At first glance the subtable may seem an unnecessary complication, but it
  turns out to be desirable for one lookup to contain several kinds of sub-table
  data. For instance, a kerning lookup might include one subtable providing
  glyph class kerning, and then another subtable providing exceptions to that
  on a glyph by glyph basis.
  <H4>
    How lookups are applied
  </H4>
  <P>
  When a word processor deals with text, it will figure out what script is
  in use in the text. Somehow it will figure out what the language is (maybe
  it will just assume the "DFLT" language, maybe the user told it the text
  was in French, maybe the locale is Spanish, ...).
  <P>
  In any script/language some features are applied by default, while others
  may be applied at the user's discression. So in English the "liga" feature
  should always be applied, while the "dlig" feature should only be applied
  if the user asked for it. (Not all programs follow this at the moment, but
  that's the theory).
  <P>
  The word processor will build up a list of features that might be active.
  Then it looks in the font and sees which of those features are available
  for this script and language. In turn each feature is composed of lookups,
  and all lookups in all active features will be marked as active.
  <P>
  Lookups will be executed in the order in which they occur in the lookup list
  (which is also the order shown in the Font Info-&gt;Lookup pane, but may
  be quite different from the order in which the features were listed). And
  all active lookups will be executed.
  <P>
  This ordering can be important. If you have both a small-caps lookup and
  a ligature lookup active, and the text is "fi" then the order of the lookups
  will probably matter. If the small-caps lookup happens first then the "fi"
  will become "<SMALL>FI</SMALL>" and the ligature feature will not be applied.
  If the ligature happens first then you will see an "fi" ligature for which
  there is probably no small-caps glyph. In one case you get small-caps, in
  another a ligature. Probably, here, you would like the small-caps lookup
  to happen first.
  <P>
  Lookup subtables make life even more interesting. When a lookup is executed
  the subtables within that lookup are activated in turn <EM>until one
  succeeds</EM>. After that no further subtables will be applied.
  <P>
  So in the kerning example mentioned above, you would want to put the special
  case glyph to glyph subtable first, and then the glyph class to class subtable
  second. When a special case combination occurs the first subtable will succeed
  (and kern the combination) and the class subtable will not be used. For
  combinations which aren't special cases, then the first subtable will fail,
  and the second will be applied.
  <H4>
    GPOS and GSUB
  </H4>
  <P>
  Up till now I have spoken as there were one list of lookups. That was a
  simplification. There are two broad classes of lookup, and two lists. There
  are those involved in manipulating the glyphs themselves (glyph substitution,
  ligation, decomposition, etc.) and those involved in positioning glyphs relative
  to others (kerning, mark attachment, etc.).
  <P>
  The GSUB table contains all the glyph substitution lookups and <EM>all</EM>
  of them will be processed before any positioning lookups are attempted.
  <P>
  The GPOS table contains all the glyph positioning lookups.
  <H3>
    <A NAME="Anchors">Anchor Points and Classes</A>
  </H3>
  <P>
  Anchor points allow fine control of the positioning of two (or several) glyphs.
  There are several different styles of attachment based on anchors: cursive,
  mark to base, mark to ligature and mark to mark positioning. The first style
  is used to join glyphs in flowing scripts (cursive) where the exit from one
  glyph joins the entry point of the next. In the second style one of the glyphs
  is the base glyph, and it will be positioned normally, the other glyph which
  will often be a diacritic or vowel mark will be positioned so that the anchor
  points in each glyph are coincident. Mark to ligature behaves similarly to
  mark to base except that there may be more that one attachment point on the
  ligature depending on which component a given mark is connected to. Finally,
  mark to mark allows you to position two marks with respect to each other
  (as you might need to do in vietnamese or hebrew where you may get several
  marks for one glyph).
  <P>
  That is badly said. Consider the following two glyphs and how they are joined
  to make the final result:
  <TABLE>
    <TR>
      <TD><IMG SRC="a_with_anchor.png" WIDTH=104 HEIGHT=208></TD>
      <TD>+</TD>
      <TD><IMG SRC="grave_with_anchor.png" WIDTH=66 HEIGHT=208></TD>
      <TD>=&gt;</TD>
      <TD><IMG SRC="agrave_anchored.png" WIDTH=104 HEIGHT=208></TD>
    </TR>
  </TABLE>
  <P>
  The grave accent has been raised and moved to the right so that its anchor
  point is positioned where the anchor from "a" was.
  <P>
  FontForge does not compose these glyphs (well, it can, but that's a completely
  different area), instead it provides information within the
  <A HREF="gposgsub.html">font</A> to a text layout program so that the program
  can do the composition.
  <P>
  The example above is unlikely to be very useful since most latin fonts contain
  pre-composed a-grave glyphs, but the same concepts apply to arabic and hebrew
  where the number of variants is larger and the precomposed glyphs fewer.
  <P>
  That's roughly how anchor points are used. Now the mechanics.
  <P>
  Each of the different attachment styles mentioned above (cursive, mark to
  base, mark to ligature and mark to mark) is a different type of GPOS lookup.
  If you want to do attachment positioning you must first create the appropriate
  lookup (<A HREF="fontinfo.html#Lookups">Element-&gt;Font
  Info-&gt;Lookups-&gt;GPOS</A>, then a lookup subtable, and then an anchor
  class within the lookup subtable. An anchor class is specified by providing
  a name for it (in the above example the class was called "Top").
  <P>
  Cursive attachments are a little different from the other attachment types.
  Each glyph has two attachment points, an entry and an exit (instead of just
  the one shown in the mark to base example above). The text layout program
  will attach the exit point of one glyph to the entry point of the next.
  <P>
  A glyph may contain several Anchor Points, but only one for each mark to
  base anchor class (ligatures may have more than one for a class, and 'curs'
  and 'mkmk' classes will usually have two). Inside a glyph may create a point
  with the <A HREF="pointmenu.html#AddAnchor">Point-&gt;Add Anchor command</A>.
  You must specify an anchor class, and whether this point is in a base glyph
  or in a mark glyph, and a location. So in the example above the anchor point
  in "a" has class "Top" and is a base glyph, while the anchor point in "grave"
  also has class "Top" but is a mark glyph. There may be many base glyphs with
  an anchor point named "Top" and many mark glyphs also with "Top" anchor points.
  Any base glyph with a "Top" anchor point maybe composed with any mark glyph
  with a "Top" anchor point. So instead of specifying the exact composed form
  for all possible combinations we specify far fewer anchor points for the
  same effect.
  <P>
  But life is not really that simple. Ligatures may need several anchor points
  of the same class (one above each component for example). When you create
  your anchor point you may say that it is to be in a ligature, in which case
  you will also be asked for a ligature index -- a number running from 0 to
  the number of components in the ligature -1. This allows you to position
  several anchor points with the same class. The text layout program will place
  the first mark over the first anchor point, the second mark over the second
  and so on (this is a gross simplification).
  <P>
  Finally you may need to position two marks based on the same anchor point,
  for example the glyph <IMG SRC="a_dieresis_macron.png" WIDTH=9 HEIGHT=14>
  has a diaeresis and a macron over it. Both of which might normally be positioned
  with the Top anchor class. Instead we define a special class for positioning
  one mark with respect to another. When creating the anchor class specify
  a tag of 'mkmk' (mark to mark) and call it something like "TopMark". When
  you create a new anchor point for diaeresis you specify that it is a <EM>base
  mark</EM> and you position it above the glyph, while the new anchor point
  in macron should be of type mark and should be positioned at the same place
  as the "Top" anchor point. Thus when given the sequence of glyphs "a diaeresis
  macron" the text layout program should position "a" normally, position
  "diaeresis" so that the its Top anchor point is where "a"'s is, and position
  macron so that its TopMark anchor point is where "diaeresis"'s is.
  <P>
  Anchor points may be selected, dragged, transformed, cut, copied and pasted.
  <H3>
    <A NAME="Baseline">Baseline</A>s
  </H3>
  <P>
  To a user of the latin alphabet it makes sense for the vertical origin of
  a glyph to be the baseline on which most letters
  rest<IMG SRC="latinBaseline.png" WIDTH="93" HEIGHT="45">. This means that
  if you change the pointsize of a glyph it will still line up
  properly<IMG SRC="latinNormalBaseline.png" WIDTH="91" HEIGHT="21">. This
  is so obvious we don't even think about it. But if you put the vertical origin
  at the top of the letter then the letters will be aligned quite differently,
  and to our eyes,
  unexpectedly<IMG SRC="latinHangBaseline.png" WIDTH="90" HEIGHT="21">.
  <P>
  Different scripts have different expectations of how glyphs should be aligned.
  In latin (cyrillic, greek, arabic, hebrew, etc.) the alignment point, the
  baseline, is somewhere in the middle of the possible extent of a glyph --
  that is the script has both ascenders above the baseline and descenders below
  it.
  <P>
  But not all scripts are like that. In Devanagari the alignment point is near
  the top of the glyph -- indeed most glyphs will draw in the baseline
  explicitly<IMG SRC="devaBaseline.png" WIDTH="97" HEIGHT="46">. If you change
  the pointsize you want glyphs to line up on this
  line<IMG SRC="devaHangBaseline.png" WIDTH="82" HEIGHT="21">, and not down
  at the bottom of the glyph
  <IMG SRC="devaLatinBaseline.png" WIDTH="76" HEIGHT="18">.
  <P>
  In CJK ideographs the baseline is usually drawn at the bottom edge of the
  square which contains the glyph.
  <P>
  However if you try and typeset these different scripts together with their
  baselines in the same place you get a mess:
  <IMG SRC="misalignedBaselines.png" WIDTH="65" HEIGHT="38">. It would be much
  nicer if it were possible to say that these different scripts have their
  baselines in different places so that the glyphs can fit together
  reasonably:<IMG SRC="alignedBaselines.png" WIDTH="65" HEIGHT="23">. Both
  Apple Typography and OpenType allow for this. There is a
  <A HREF="baseline.html">baseline table </A>which says how the baselines for
  each script (or each glyph) should be aligned with respect to other baselines.
  <H3>
    <A NAME="FontView">Font View</A>
  </H3>
  <P>
  The <A HREF="fontview.html">font view</A> displays all the glyphs in the
  font (or all that will fit in the window). Every line has two parts, at the
  top is a label, often small clear letters, underneath that, somewhat larger
  is a 24 pixel rasterization of the font you have designed. As you edit a
  glyph in an <A HREF="#CharView">outline glyph view</A> its small version
  in the font view will change as you work.
  <P>
  Double-clicking on a glyph will bring up an outline glyph view of that glyph
  which will allow you to edit it.
  <P>
  Selecting several glyphs will allow you to apply various operations to all
  of them, or to cut and paste them.
  <P>
  <IMG SRC="AmbrosiaFV.png" WIDTH="423" HEIGHT="226">
  <P>
  Fonts do not need to be for the latin alphabet alone. Below is a view of
  one of <A HREF="ftp://ftp.ipl.t.u-tokyo.ac.jp/Font/">Wadalab</A>'s public
  domain Kanji fonts...
  <P>
  <IMG SRC="kanjifont.png" WIDTH="423" HEIGHT="212">
  <P>
  Another Wadalab font encapsulated in a CID keyed font
  <P>
  <IMG SRC="fontview-cid.png" WIDTH="573" HEIGHT="226">
  <H3>
    <A NAME="CharView">Outline Glyph View</A>
  </H3>
  <P>
  The <A HREF="charview.html">outline view</A> is probably the most complex
  view in FontForge. This is where you actually edit the splines
  (<A HREF="bezier.html">B&eacute;zier splines</A>) that make up your glyphs.
  <P>
  You may have a background image loaded into the view to help you trace out
  the shape you are working on (it is displayed in grey). There are various
  grid lines visible, some created by default (the baseline, the ascent line,
  the descent line, and a line at x=0), you may add others yourself.
  <P>
  There is a layer showing the glyph's hints.
  <P>
  In the foreground are the splines and points of the glyph itself, and the
  width line (you may adjust the glyph's width by moving this line). If a point
  is selected then its control points will be displayed.
  <P>
  To the left of the main window (the image below shows them on the right,
  that was just to keep them from crowding things, you can move them around)
  are two palettes, one a palette of tools, and the other a palette controlling
  what layers (foreground, background, grid, hints) are visible and editable.
  <P>
  <IMG SRC="charview2.png" WIDTH="544" HEIGHT="656">
  <H3>
    <A NAME="BitmapView">Bitmap View</A>
  </H3>
  <P>
  The <A HREF="bitmapview.html">bitmap view</A> is similar to the outline view
  above. It also has a tools and layer palette.
  <P>
  This allows you to edit bitmap versions of the outline glyphs you create
  above.
  <P>
  In the background is a small rendition of the outline, and in the foreground
  are the bits of the image. You may make the program calculate which bits
  should be set by pressing the "Recalculate button", the results usually need
  to be tweaked by hand. In the upper left corner is a full sized image of
  your bitmap glyph.
  <P>
  <IMG SRC="BitmapView.png" WIDTH="254" HEIGHT="273">
  <H3>
    <A NAME="MetricsView">Metrics View</A>
  </H3>
  <P>
  The <A HREF="metricsview.html">metrics view</A> allows you to see how the
  glyphs look together.
  <P>
  You can change the width and left/right bearings of a glyph, either by dragging
  in the upper part of the window or by entering an appropriate number in the
  lower.
  <P>
  You can also provide kerning information for any two adjacent glyphs. You
  can view how various OpenType features affect the glyph stream
  <TABLE>
    <TR>
      <TD><IMG SRC="MetricsView.png" WIDTH="479" HEIGHT="331"></TD>
      <TD><IMG SRC="MetricsView-features.png" WIDTH="463" HEIGHT="330"></TD>
    </TR>
  </TABLE>
  <P>
  <IMG SRC="VerticalMetrics.png" WIDTH="270" HEIGHT="573" ALIGN="Right">Note
  that in Hebrew, or Arabic (or any other right to left alphabet) the glyphs
  will start on the right and run to the left. While in CJK fonts you may want
  to see things arranged vertically.
  <P>
  <IMG SRC="HebrewMetrics.png" WIDTH="511" HEIGHT="323">
  <P>
  <P>
  <P ALIGN=Center>
  -- <A HREF="editexample.html">Next</A> --
</DIV>
</BODY></HTML>
